Parameterization in TestNG

Parameterization is a TestNG feature that allows testers to pass external values to test methods instead of hard-coding those values directly inside the test code. In Selenium automation, parameterization is commonly used to run the same test with different browsers, URLs, usernames, passwords, environments, search values, or other configuration data.

Parameterization makes Selenium automation frameworks more flexible, reusable, maintainable, and suitable for executing the same test scenario under different conditions.

Instead of creating separate test methods for Chrome, Firefox, and Edge, for example, a single test method can receive the browser name as a parameter and execute the appropriate browser configuration.

Course Resource: Selenium Training | Register for Course Demo

1. What is Parameterization?

Parameterization is the process of supplying input values to a test from an external configuration or data source instead of hard-coding those values in the test method.

In TestNG, parameters can commonly be supplied through the testng.xml configuration file using the <parameter> element and received in Java using the @Parameters annotation.

testng.xml

     |
     v
Parameter Values
     |
     v
@Parameters
     |
     v
Test Method
     |
     v
Selenium WebDriver
     |
     v
Application

2. Why is Parameterization Important?

Parameterization is important because automation tests frequently need to run with different input values or configurations.

• Run the same test with different browsers.
• Run tests against different environments.
• Pass different usernames and passwords.
• Reuse the same test method with different URLs.
• Reduce duplicate test code.
• Make test configuration easier to maintain.
• Support cross-browser testing.
• Support environment-specific execution.
• Make automation frameworks more reusable.
• Integrate tests more easily with CI/CD pipelines.

3. Parameterization Flow

TestNG XML

    |
    v
Parameter Definition
    |
    v
@Parameters Annotation
    |
    v
Java Test Method
    |
    v
Receive Parameter
    |
    v
Perform Selenium Action
    |
    v
Validate Result

4. Parameterization in Selenium

Selenium WebDriver itself does not provide TestNG parameterization. TestNG provides the parameterization mechanism, while Selenium uses the received values to control browser automation.

For example, TestNG can provide the browser name and Selenium can use that value to decide which WebDriver should be created.

TestNG Parameter

       |
       v
"chrome"
       |
       v
ChromeDriver
       |
       v
Selenium WebDriver
       |
       v
Web Application

5. TestNG @Parameters Annotation

The @Parameters annotation is used to receive parameter values defined in the TestNG XML configuration.

import org.testng.annotations.Parameters;

import org.testng.annotations.Test;
 
public class LoginTest {
 
    @Test
    @Parameters("username")
    public void loginTest(String username) {
        System.out.println("Username: " + username);
    }
}

6. Defining a Parameter in testng.xml

The parameter value can be defined using the <parameter> element.

<suite name="Parameter Suite">

 
    <parameter name="username" value="admin"/>
 
    <test name="Login Test">
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
</suite>

7. Complete Parameterization Example

import org.testng.annotations.Parameters;

import org.testng.annotations.Test;
 
public class LoginTest {
 
    @Test
    @Parameters("username")
    public void loginTest(String username) {
 
        System.out.println("Username: " + username);
    }
}

<?xml version="1.0" encoding="UTF-8"?>

 
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
 
<suite name="Parameter Suite">
 
    <parameter name="username" value="admin"/>
 
    <test name="Login Tests">
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
</suite>

8. Passing Multiple Parameters

TestNG allows multiple parameters to be supplied to a test method.

<suite name="Login Suite">

 
    <parameter name="username" value="admin"/>
    <parameter name="password" value="admin123"/>
 
    <test name="Login Test">
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
</suite>

import org.testng.annotations.Parameters;

import org.testng.annotations.Test;
 
public class LoginTest {
 
    @Test
    @Parameters({"username", "password"})
    public void loginTest(String username, String password) {
 
        System.out.println("Username: " + username);
        System.out.println("Password: " + password);
    }
}

9. Parameterizing Browser Name

One of the most common uses of parameterization in Selenium is selecting the browser dynamically.

<suite name="Browser Suite">

 
    <test name="Chrome Test">
        <parameter name="browser" value="chrome"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
</suite>

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
 
public class LoginTest {
 
    @Test
    @Parameters("browser")
    public void loginTest(String browser) {
 
        WebDriver driver;
 
        if (browser.equalsIgnoreCase("chrome")) {
            driver = new ChromeDriver();
        } else {
            throw new IllegalArgumentException("Unsupported browser: " + browser);
        }
 
        driver.get("https://example.com");
 
        System.out.println("Browser: " + browser);
 
        driver.quit();
    }
}

10. Cross-Browser Parameterization

Parameterization can be combined with multiple TestNG <test> sections to execute the same test class using different browser configurations.

<suite name="Cross Browser Suite" parallel="tests" thread-count="3">

 
    <test name="Chrome Tests">
        <parameter name="browser" value="chrome"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
    <test name="Firefox Tests">
        <parameter name="browser" value="firefox"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
    <test name="Edge Tests">
        <parameter name="browser" value="edge"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
</suite>

11. Browser Parameter with WebDriver

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.edge.EdgeDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
 
public class BrowserTest {
 
    @Test
    @Parameters("browser")
    public void openBrowser(String browser) {
 
        WebDriver driver;
 
        switch (browser.toLowerCase()) {
            case "chrome":
                driver = new ChromeDriver();
                break;
 
            case "firefox":
                driver = new FirefoxDriver();
                break;
 
            case "edge":
                driver = new EdgeDriver();
                break;
 
            default:
                throw new IllegalArgumentException(
                    "Unsupported browser: " + browser
                );
        }
 
        driver.get("https://example.com");
 
        System.out.println("Running test on: " + browser);
 
        driver.quit();
    }
}

12. Parameterizing Application URL

The application URL can also be supplied through TestNG XML.

<suite name="Environment Suite">

 
    <parameter name="url" value="https://example.com"/>
 
    <test name="Application Test">
        <classes>
            <class name="tests.HomePageTest"/>
        </classes>
    </test>
 
</suite>

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
 
public class HomePageTest {
 
    @Test
    @Parameters("url")
    public void openApplication(String url) {
 
        WebDriver driver = new ChromeDriver();
 
        driver.get(url);
 
        System.out.println("Application URL: " + url);
 
        driver.quit();
    }
}

13. Environment Parameterization

Parameterization is useful when the same Selenium test must run against different environments such as development, testing, staging, and production-like environments.

<suite name="Environment Suite">

 
    <test name="Staging Test">
        <parameter name="environment" value="staging"/>
        <parameter name="url" value="https://staging.example.com"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
</suite>

14. Environment-Based Selenium Test

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
 
public class EnvironmentTest {
 
    @Test
    @Parameters({"environment", "url"})
    public void verifyEnvironment(String environment, String url) {
 
        WebDriver driver = new ChromeDriver();
 
        System.out.println("Environment: " + environment);
 
        driver.get(url);
 
        System.out.println("URL: " + driver.getCurrentUrl());
 
        driver.quit();
    }
}

15. Parameterizing Username and Password

Login tests often require different credentials. Parameterization can be used to pass test credentials into the test method.

<suite name="Login Suite">

 
    <test name="Login Test">
 
        <parameter name="username" value="testuser"/>
        <parameter name="password" value="test123"/>
 
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
 
    </test>
 
</suite>

import org.testng.annotations.Parameters;

import org.testng.annotations.Test;
 
public class LoginTest {
 
    @Test
    @Parameters({"username", "password"})
    public void loginTest(String username, String password) {
 
        System.out.println("Username: " + username);
        System.out.println("Password: " + password);
 
        // Enter username
        // Enter password
        // Click login
        // Validate result
    }
}

16. Parameterizing Search Data

Search values can also be supplied externally.

<parameter name="searchText" value="laptop"/>

@Test

@Parameters("searchText")
public void searchProduct(String searchText) {
 
    System.out.println("Searching for: " + searchText);
 
    // Enter searchText in search field
    // Click search
    // Validate search results
}

17. Parameterizing Test Data

Parameterization can be used for small sets of configuration or input values. When the same test needs to execute against many combinations of data, TestNG @DataProvider is often more appropriate.

@Test(dataProvider = "loginData")

public void loginTest(String username, String password) {
    System.out.println(username + " - " + password);
}

18. @Parameters vs @DataProvider

19. Parameterization with @Optional

TestNG provides @Optional for defining a default value when a named parameter is not supplied through the configuration.

import org.testng.annotations.Optional;

import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
 
public class BrowserTest {
 
    @Test
    @Parameters("browser")
    public void openBrowser(@Optional("chrome") String browser) {
 
        System.out.println("Browser: " + browser);
    }
}

If the browser parameter is not supplied, the test method can use chrome as its default value.

20. Parameterization with @BeforeMethod

Parameters can also be received by configuration methods when the framework design requires it.

import org.testng.annotations.BeforeMethod;

import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
 
public class LoginTest {
 
    @BeforeMethod
    @Parameters("browser")
    public void setup(String browser) {
        System.out.println("Starting browser: " + browser);
    }
 
    @Test
    public void loginTest() {
        System.out.println("Executing login test");
    }
}

21. Parameterization with @BeforeTest

TestNG parameters can also be used with @BeforeTest configuration methods.

import org.testng.annotations.BeforeTest;

import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
 
public class ApplicationTest {
 
    @BeforeTest
    @Parameters("environment")
    public void setupEnvironment(String environment) {
        System.out.println("Environment: " + environment);
    }
 
    @Test
    public void verifyApplication() {
        System.out.println("Application test");
    }
}

22. Parameterization with @BeforeSuite

Suite-level configuration can also receive parameters when a value needs to be initialized before the suite execution.

import org.testng.annotations.BeforeSuite;

import org.testng.annotations.Parameters;
 
public class SuiteSetup {
 
    @BeforeSuite
    @Parameters("environment")
    public void setup(String environment) {
        System.out.println("Starting suite for: " + environment);
    }
}

23. Parameter Scope

The location where a parameter is declared affects which tests can access it. TestNG XML commonly allows parameters to be defined at suite level or test level.

24. Suite-Level Parameter

<suite name="Global Configuration">

 
    <parameter name="browser" value="chrome"/>
 
    <test name="Login">
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
    <test name="Search">
        <classes>
            <class name="tests.SearchTest"/>
        </classes>
    </test>
 
</suite>

25. Test-Level Parameter

<suite name="Application Suite">

 
    <test name="Chrome Test">
        <parameter name="browser" value="chrome"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
    <test name="Firefox Test">
        <parameter name="browser" value="firefox"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
</suite>

26. Overriding Parameters

A parameter defined closer to the test can be used to provide a more specific configuration for that test section.

<suite name="Browser Suite">

 
    <parameter name="browser" value="chrome"/>
 
    <test name="Firefox Test">
        <parameter name="browser" value="firefox"/>
 
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
</suite>

27. Parameterization for Multiple Browsers

A professional Selenium framework can use the same test class for multiple browsers by providing different parameter values in separate TestNG test sections.

<suite name="Multi Browser Suite" parallel="tests" thread-count="3">

 
    <test name="Chrome">
        <parameter name="browser" value="chrome"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
    <test name="Firefox">
        <parameter name="browser" value="firefox"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
    <test name="Edge">
        <parameter name="browser" value="edge"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
</suite>

28. Parameterization with Page Object Model

Parameterization works well with the Page Object Model. TestNG can provide the configuration value, the test class can manage the scenario, and page classes can handle UI interactions.

TestNG Parameter

       |
       v
Test Class
       |
       v
Page Object
       |
       v
WebDriver
       |
       v
Application

29. POM Example with Parameterized Login

public class LoginPage {

 
    private WebDriver driver;
 
    public LoginPage(WebDriver driver) {
        this.driver = driver;
    }
 
    public void enterUsername(String username) {
        // locate username field
        // send username
    }
 
    public void enterPassword(String password) {
        // locate password field
        // send password
    }
 
    public void clickLogin() {
        // click login button
    }
}

public class LoginTest {

 
    @Test
    @Parameters({"username", "password"})
    public void loginTest(String username, String password) {
 
        LoginPage loginPage = new LoginPage(driver);
 
        loginPage.enterUsername(username);
        loginPage.enterPassword(password);
        loginPage.clickLogin();
    }
}

30. Parameterization and Assertions

Parameters can be used to define expected values, while assertions validate the actual application result.

@Test

@Parameters({"url", "expectedTitle"})
public void verifyTitle(String url, String expectedTitle) {
 
    driver.get(url);
 
    String actualTitle = driver.getTitle();
 
    Assert.assertEquals(actualTitle, expectedTitle);
}

31. Parameterizing Expected Page Title

<suite name="Title Validation Suite">

 
    <test name="Home Page">
 
        <parameter name="url" value="https://example.com"/>
        <parameter name="expectedTitle" value="Example Domain"/>
 
        <classes>
            <class name="tests.TitleTest"/>
        </classes>
 
    </test>
 
</suite>

32. Parameterization for Different User Roles

Applications often contain different roles such as administrator, manager, employee, and customer. Parameters can be used to select the role for a test scenario.

<parameter name="role" value="admin"/>

@Test

@Parameters("role")
public void verifyDashboard(String role) {
 
    System.out.println("Testing dashboard for role: " + role);
 
    // Login based on role
    // Navigate to dashboard
    // Validate dashboard
}

33. Parameterizing Language

Parameterization can also be used when an application supports multiple languages.

<test name="Language Test">

    <parameter name="language" value="English"/>
 
    <classes>
        <class name="tests.LanguageTest"/>
    </classes>
</test>

@Test

@Parameters("language")
public void verifyLanguage(String language) {
 
    System.out.println("Testing language: " + language);
}

34. Parameterizing Application Theme

For applications supporting multiple themes, configuration values can also be passed through TestNG.

<parameter name="theme" value="dark"/>

@Test

@Parameters("theme")
public void verifyTheme(String theme) {
 
    System.out.println("Testing theme: " + theme);
}

35. Parameterizing Test Data vs Configuration

It is important to distinguish configuration parameters from large test-data sets.

TestNG XML parameters are especially suitable for configuration. For larger data-driven scenarios, @DataProvider, CSV, Excel, databases, or other external data sources may be more appropriate.

36. Parameterization with DataProvider

When a test must execute multiple times with different input combinations, a DataProvider can supply the data.

import org.testng.annotations.DataProvider;

import org.testng.annotations.Test;
 
public class LoginTest {
 
    @DataProvider(name = "loginData")
    public Object[][] loginData() {
        return new Object[][] {
            {"user1", "password1"},
            {"user2", "password2"},
            {"user3", "password3"}
        };
    }
 
    @Test(dataProvider = "loginData")
    public void loginTest(String username, String password) {
 
        System.out.println(
            "Testing: " + username + " / " + password
        );
    }
}

37. Combining XML Parameters and DataProvider

Advanced frameworks can use XML parameters for environment or browser configuration and DataProviders for multiple test-data records.

Browser Configuration

        |
        v
testng.xml
        |
        v
Selenium WebDriver
 
Test Data
        |
        v
@DataProvider
        |
        v
Test Method

This separation keeps framework configuration and test data conceptually distinct.

38. Parameterization with Maven

Parameterization can be combined with Maven-based automation projects. Maven can trigger the TestNG suite, while TestNG XML provides the required test configuration.

pom.xml

   |
   v
Maven Test Execution
   |
   v
testng.xml
   |
   v
Parameters
   |
   v
Selenium Tests

39. Parameterization in CI/CD

Parameterization becomes particularly useful in CI/CD because the same automation code may need to run against different environments or browsers.

CI/CD Pipeline

      |
      v
Select Environment
      |
      v
Provide Configuration
      |
      v
Run TestNG Suite
      |
      v
Selenium WebDriver
      |
      v
Test Results

40. Parameterization and Jenkins

A CI server such as Jenkins can trigger an automation job with configuration values. The exact mechanism depends on the Jenkins job and build configuration, but the general concept is to keep environment-specific configuration outside the test implementation.

Jenkins Job

    |
    +-- Environment = staging
    |
    +-- Browser = chrome
    |
    v
TestNG Suite
    |
    v
Selenium Tests

41. Handling Unsupported Parameter Values

Automation code should validate parameters before using them. This prevents unexpected configuration values from producing confusing failures.

@Test

@Parameters("browser")
public void browserTest(String browser) {
 
    if (browser == null || browser.isBlank()) {
        throw new IllegalArgumentException(
            "Browser parameter is required"
        );
    }
 
    switch (browser.toLowerCase()) {
        case "chrome":
            System.out.println("Chrome selected");
            break;
 
        case "firefox":
            System.out.println("Firefox selected");
            break;
 
        case "edge":
            System.out.println("Edge selected");
            break;
 
        default:
            throw new IllegalArgumentException(
                "Unsupported browser: " + browser
            );
    }
}

42. Parameterization and Null Values

A test should not assume that a required parameter is always available. Required configuration should be validated before it is used.

@Test

@Parameters("username")
public void verifyUsername(String username) {
 
    if (username == null || username.isBlank()) {
        throw new IllegalArgumentException(
            "Username parameter is required"
        );
    }
 
    System.out.println(username);
}

43. Parameterization for Login Automation Framework

<suite name="Login Automation Suite">

 
    <parameter name="browser" value="chrome"/>
    <parameter name="environment" value="staging"/>
    <parameter name="username" value="testuser"/>
    <parameter name="password" value="test123"/>
 
    <test name="Login Tests">
 
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
 
    </test>
 
</suite>

import org.testng.annotations.Parameters;

import org.testng.annotations.Test;
 
public class LoginTest {
 
    @Test
    @Parameters({
        "browser",
        "environment",
        "username",
        "password"
    })
    public void loginTest(
            String browser,
            String environment,
            String username,
            String password) {
 
        System.out.println("Browser: " + browser);
        System.out.println("Environment: " + environment);
        System.out.println("Username: " + username);
 
        // Initialize browser
        // Open environment URL
        // Enter username
        // Enter password
        // Click login
        // Validate login result
    }
}

44. Real-World E-Commerce Parameterization

Consider an e-commerce application where the same test must run against different browsers and environments.

<suite name="E-Commerce Suite" parallel="tests" thread-count="2">

 
    <test name="Chrome Staging">
        <parameter name="browser" value="chrome"/>
        <parameter name="environment" value="staging"/>
 
        <classes>
            <class name="tests.ECommerceTest"/>
        </classes>
    </test>
 
    <test name="Firefox Staging">
        <parameter name="browser" value="firefox"/>
        <parameter name="environment" value="staging"/>
 
        <classes>
            <class name="tests.ECommerceTest"/>
        </classes>
    </test>
 
</suite>

45. Parameterization for API and UI Environments

In larger automation frameworks, both UI and API endpoints can be supplied as configuration values.

<parameter name="uiUrl" value="https://example.com"/>

<parameter name="apiUrl" value="https://api.example.com"/>

This approach can help keep environment-specific URLs outside the test implementation.

46. Parameterization and Reusable Driver Factory

A reusable Driver Factory can receive the browser parameter and create the appropriate WebDriver.

public class DriverFactory {

 
    public static WebDriver createDriver(String browser) {
 
        switch (browser.toLowerCase()) {
 
            case "chrome":
                return new ChromeDriver();
 
            case "firefox":
                return new FirefoxDriver();
 
            case "edge":
                return new EdgeDriver();
 
            default:
                throw new IllegalArgumentException(
                    "Unsupported browser: " + browser
                );
        }
    }
}

47. Parameterized Test Execution Flow

testng.xml

     |
     v
Read Parameters
     |
     v
Create Test Instance
     |
     v
Pass Values to Method
     |
     v
Create WebDriver
     |
     v
Execute Selenium Actions
     |
     v
Assertions
     |
     v
Test Result

48. Advantages of Parameterization

• Reusability: The same test logic can work with different values.
• Maintainability: Configuration values can be separated from Java code.
• Flexibility: Browser and environment values can be changed without changing test logic.
• Reduced Duplication: Separate test methods are not required for every configuration.
• Cross-Browser Support: The same test class can run against different browsers.
• Environment Support: Tests can run against different application environments.
• CI/CD Compatibility: Automated pipelines can use different configurations.
• Scalability: Parameterization supports larger automation frameworks.

49. Limitations of XML Parameterization

• It is primarily intended for configuration-style values.
• It is not the best choice for very large data sets.
• Complex test-data combinations can become difficult to manage in XML.
• Sensitive credentials should not be casually hard-coded in XML files.
• Large numbers of parameters can make test methods difficult to read.

50. Parameterization vs Hard-Coding

51. Parameterization vs DataProvider

52. Parameterization vs Properties Configuration

53. Common Mistakes in Parameterization

54. Best Practices for Parameterization

1. Use meaningful parameter names.
2. Keep configuration values separate from test logic.
3. Use @Parameters for suite or execution configuration.
4. Use @DataProvider for repeated test-data combinations.
5. Validate parameter values before using them.
6. Use sensible defaults where appropriate.
7. Avoid hard-coding environment-specific values.
8. Do not expose sensitive credentials in source-controlled XML files.
9. Keep test methods readable.
10. Use a Driver Factory for browser creation in larger frameworks.
11. Combine parameterization with Page Object Model for maintainability.
12. Design parallel tests to avoid shared mutable state.
13. Use CI/CD configuration mechanisms for environment-specific values.

55. Parameterization with Parallel Execution

Parameterization and parallel execution can be combined to run the same test configuration across different browsers.

<suite name="Parallel Browser Suite"

       parallel="tests"
       thread-count="3">
 
    <test name="Chrome">
        <parameter name="browser" value="chrome"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
    <test name="Firefox">
        <parameter name="browser" value="firefox"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
    <test name="Edge">
        <parameter name="browser" value="edge"/>
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
    </test>
 
</suite>

When running browsers in parallel, WebDriver instances should be isolated so that one test does not accidentally use another test's driver or shared state.

56. Parameterization and Reporting

Reports become more useful when they identify the configuration under which a test was executed.

• Browser name.
• Environment.
• Test name.
• Test class.
• Test method.
• Execution status.
• Failure reason.
• Execution duration.

57. Practical Project Structure

SeleniumAutomationProject

|
+-- src
|   |
|   +-- main
|   |   |
|   |   +-- java
|   |       +-- pages
|   |       +-- utilities
|   |       +-- base
|   |
|   +-- test
|       |
|       +-- java
|           +-- tests
|               +-- LoginTest.java
|               +-- SearchTest.java
|               +-- CheckoutTest.java
|
+-- testng.xml
+-- pom.xml
+-- config.properties
+-- reports
+-- screenshots

58. Complete Practical Parameterization Example

The following example demonstrates browser, environment, username, and password parameters being passed to a Selenium test.

<?xml version="1.0" encoding="UTF-8"?>

 
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
 
<suite name="Selenium Parameterized Suite">
 
    <parameter name="browser" value="chrome"/>
    <parameter name="environment" value="staging"/>
 
    <test name="Login Automation">
 
        <parameter name="username" value="testuser"/>
        <parameter name="password" value="test123"/>
 
        <classes>
            <class name="tests.LoginTest"/>
        </classes>
 
    </test>
 
</suite>

package tests;

 
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.Assert;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
 
public class LoginTest {
 
    @Test
    @Parameters({
        "browser",
        "environment",
        "username",
        "password"
    })
    public void loginTest(
            String browser,
            String environment,
            String username,
            String password) {
 
        WebDriver driver = null;
 
        try {
 
            if (browser.equalsIgnoreCase("chrome")) {
                driver = new ChromeDriver();
            } else {
                throw new IllegalArgumentException(
                    "Unsupported browser: " + browser
                );
            }
 
            String url = "https://example.com";
 
            driver.get(url);
 
            System.out.println("Environment: " + environment);
            System.out.println("Username: " + username);
 
            String actualUrl = driver.getCurrentUrl();
 
            Assert.assertNotNull(actualUrl);
 
        } finally {
 
            if (driver != null) {
                driver.quit();
            }
        }
    }
}

59. Real-World Parameterization Architecture

                TestNG XML

                    |
        +-----------+-----------+
        |           |           |
        v           v           v
     Browser    Environment   Test Config
        |           |           |
        +-----------+-----------+
                    |
                    v
               Test Class
                    |
                    v
              Driver Factory
                    |
                    v
             Page Object Model
                    |
                    v
             Selenium WebDriver
                    |
                    v
              Web Application
                    |
                    v
                Assertions
                    |
                    v
                 Reports

60. Interview Questions on Parameterization

1. What is parameterization in TestNG?
2. Why is parameterization used in Selenium automation?
3. What is the purpose of the @Parameters annotation?
4. How do you define a parameter in testng.xml?
5. How do you pass multiple parameters to a test method?
6. How can you parameterize a browser in Selenium?
7. How can you perform cross-browser testing using TestNG parameters?
8. What is the difference between @Parameters and @DataProvider?
9. What is @Optional in TestNG?
10. Where can TestNG parameters be defined?
11. What happens if a required parameter is not supplied?
12. How can environment URLs be parameterized?
13. How can username and password be passed to a test?
14. Can parameters be used with @BeforeMethod?
15. Can parameters be used with @BeforeSuite?
16. How can parameters be combined with Page Object Model?
17. How can parameterization be combined with parallel execution?
18. What are the advantages of parameterization?
19. What are common mistakes in TestNG parameterization?
20. How is parameterization used in CI/CD automation?

61. Quick Reference Table

62. Learning Roadmap for Parameterization

TestNG Basics

      |
      v
TestNG Annotations
      |
      v
testng.xml
      |
      v
@Parameters
      |
      v
Single Parameter
      |
      v
Multiple Parameters
      |
      v
Browser Parameterization
      |
      v
Environment Parameterization
      |
      v
Cross-Browser Testing
      |
      v
@DataProvider
      |
      v
Page Object Model
      |
      v
Parallel Execution
      |
      v
Maven Integration
      |
      v
CI/CD Integration
      |
      v
Complete Selenium Automation Framework

63. Summary

Parameterization is an important TestNG feature used to provide external configuration values to Selenium automation tests. Instead of hard-coding browser names, URLs, environments, roles, or other configuration values, testers can define those values in the TestNG XML configuration and receive them using the @Parameters annotation.

Parameterization is especially useful for cross-browser testing, environment-specific execution, reusable test methods, CI/CD execution, and scalable Selenium frameworks. For larger data-driven scenarios, TestNG @DataProvider or suitable external data sources can be used.

A professional Selenium framework commonly combines parameterization with Selenium WebDriver, Page Object Model, Driver Factory, TestNG groups, assertions, reporting, Maven, and CI/CD tools to create a reusable and maintainable automation solution.

64. Course Resources

Learn Selenium Automation Testing: JustAcademy Selenium Training

Register for Course Demo: Register for Selenium Training Demo